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DETAILED ACTION 

1. A request for continued examination under 37 CFR 1.114, including the fee set 
forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this 
application is eligible for continued examination under 37 CFR 1.114, and the fee set 
forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action 
has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 20 
August 2004 has been entered. 

2. The following is a First Office Action in response to the request for continued 
examination filed 20 August 2004. Applicant's amendment of 20 August 2004 amended 
claims 1, 7, 8, 11, 13 and 15-17 and canceled claim 12. Currently, claims 1-4, 6-11, 
and 13-17 are pending in this application and have been examined on the merits as 
discussed below. 

Specification 

3. The disclosure is objected to because of the following informalities: on page 3, 
lines 19-20, delete "This might be the case with orders involve large amounts of money, 
for example", and insert -- This might be the case with orders that involve large 
amounts of money, for example -. Appropriate correction is required. 

Claim Objections 

4. Claims 8 and 1 5 are objected to because of the following informalities: 
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- Claim 8, line 2, delete "process object to transitions", and insert - process 
object transitions --. 

- Claim 15 is dependent to claim 12, however claim 12 has been canceled. For 
examination purposes, claim 15 is considered dependent to claim 7. 

Appropriate correction is required. 

Response to Arguments 

5. Applicant's arguments, see p. 6-8 of the Preliminary Amendment, filed 20 August 
2004, with respect to the rejection of claims 1 and 6 under 35 U.S.C. 102 (a) and 35 
U.S.C. 103(a), respectively, have been fully considered and are persuasive. Therefore, 
the rejection has been withdrawn. However, upon further consideration, a new 
ground(s) of rejection is made in view of Barkley (U.S. Patent 6,088,679) and Gabbita et 
al. (U.S. Patent 6,349,238) and Kiely (Kiely, XML: More Than Just A Quick Fix, 
InformationWeek Online, 8 February 1999 [GOOGLE]). Applicant asserts that Barkley 
does not disclose or suggest designating a task, associated with the activity state, as 
reassignable to indicate that the task may be moved between performers of the activity 
state. Gabitta et al. teach workflow steps can be transferred and re-assigned using the 
remote workstations. Please see the 35 U.S.C. 103(a) rejections below. 

6. Applicant's arguments with respect to claim 16 have been considered but are 
moot in view of the new ground(s) of rejection. Applicant amended claim 16 to further 
stipulate that if the activity state is define as an automated step, then performing the 
activity through the use of an application program to complete the step. Barkley 
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teaches the Workflow Management System defines, creates and manages the 
execution of workflows through the use of software, running on one or more workflow 
engines, which is able to interpret the process definition, interact with workflow 
participants, and, where required, invoke the use of information technology tools and 
applications. Please see the 35 U.S.C, 103(a) rejection below. 
7. Applicant's arguments, see p. 7-8 of the Preliminary Amendment, filed 20 August 
2004, with respect to the rejection of claim 17 under 35 U.S.C. 102 (a) have been fully 
considered and are persuasive. Therefore, the rejection has been withdrawn. 
However, upon further consideration, a new ground(s) of rejection is made in view of 
Barkley (U.S. Patent 6,088,679) and Gabbita et al. (U.S. Patent 6,349,238). Applicant 
asserts' Barkley does not disclose that each performer can trigger additional events as a 
result of task operation, as needed. Gabbita et al. teach means to coordinate all the 
tasks and activities related to order processing among the various entities within the 
telecommunications company. Work plans are used to model business procedures 
used for processing Service Orders. Each Work Plan comprises a plurality of workflow 
steps. Business process models are depicted as workflow diagrams. Resources are 
individuals, groups, and/or computer systems. Users can log-on to remote workstations 
attached to a company-wide Intranet or the like. Viewing the In-Box is one way in which 
users are notified of the assignment and its associated due date. If a Service Order is 
delayed, users can immediately determine information about the delay and take 
corrective action before it becomes critical. Workflow steps can be transferred and re- 
assigned using the remote workstations. The examiner interprets that when a user is 
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working on a Work Plan, they can transfers or re re-assigns a workflow step, which will 
trigger an additional step of at least notifying the new designated performer by placing 
the new work step in their In-Box. Please see the 35 U.S.C. 103(a) rejection below. 

8. Applicant's arguments with respect to claim 7 have been considered but are moot 
in view of the new ground(s) of rejection. Applicant amended claim 7 to include the 
steps of completing the task, wherein any changes made to the business process 
reference data during completion of the task are collected and updating the business 
process object reference data to incorporate any changes that were made during 
execution of the activity state. Barkley teaches that in a RBAC system, access to 
objects is managed at a level corresponding closely to the organization's structure. 
Each user is assigned one or more "roles", and each "role" is assigned one or more 
"permissions" that are authorized for users in that role. The operations provided for 
each role correspond to the duties and responsibilities of the person having that role in 
the organization. Gabbita et al. teach a History File of significant events that occur with 
the system as it pertains to each Service Order. The events include transaction 
processing activities, system access information, and administrative manipulation of 
system data. History File data for Work Steps include actual step completion times as 
well as planned start and finish times. Please see the 35 U.S.C. 103(a) rejection below. 

Claim Rejections - 35 USC § 103 

9. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 
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(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

10. Claims 1-4, 7-11, and 13-17 are rejected under 35 U.S.C. 103(a) as being 

unpatentable over Barkley (U.S. Patent 6,088,679) in view of Gabbita et al. (U.S. Patent 

6,349,238). Barkley discloses a method for incorporating human-based activities in 

business process models comprising: 

- [Claim 1] defining an activity state, the activity state corresponding to a 
human-based or manual step (col. 4, lines 49-55, Barkley teaches an activity 
as a description of a piece of work that forms one logical step within a 
process. An activity is typically the smallest unit of work which is scheduled 
by a workflow engine during process enactment (e.g. using transition and 
pre/post-conditions), although one activity may result in several work items 
being assign (to a workflow participant).); 

- identifying one or more performers for the activity state (col. 4, lines 9-29, 
Barkley teaches Role-Based Access Control (RBAS) is used to define 
membership of individuals in groups, i.e., to assign individuals to roles, to 
assign permission to roles, and to then activate the roles with respect to the 
process at appropriate points in the sequence.); 

Barkley fails to teach designating a task, associated with the activity state, as 

reassignable to indicate that the task may be.moved between performers of the activity 

state. Gabbita et al. teach means to coordinate all the tasks and activities related to 

order processing among the various entities within the telecommunications company. 

Work plans are used to model business procedures used for processing Service 

Orders. Each Work Plan comprises a plurality of workflow steps. Business process 

models are depicted as workflow diagrams and Resources are individuals, groups, 

and/or computer systems. Users can log-on to remote workstations attached to a 

company-wide Intranet or the like. If a Service Order is delayed, users can immediately 
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determine information about the delay and take corrective action before it becomes 
critical. Workflow steps can be transferred and re-assigned using the remote 
workstations (col. 1, lines 65-67, col. 2, lines 22-25, lines 36-37, and lines 65-66, and 
col. 3, lines 7-10). Inherently a task is designated as reassignable since it is identified 
that the user can transfer and re-assign the workflow steps. It would have been obvious 
to one of ordinary skill in the art at the time of the applicant's invention to include the 
capability to re-assign a task of Gabbita et al. with Barkley since Barkley teaches that it 
is old and well known in the art to automate a business process, in whole or in part, 
during which documents, information or tasks are passed from one participant to 
another for action, according to a set of procedural rules (col. 5, lines 45-49). Workflow 
technology allows companies to reduce cost and improve efficiency of the operation. 
Role-Based Access Control (RBAC) ,is a methodology for controlling access to a 
computer system, whereby RBAC reduces administrative cost and complexity as 
compared to other access control mechanisms (Barkley: col. 2, lines 51-60). Gabbita et 
al. presents an efficient and economical system and method for processing 
telecommunication orders and for managing and tracking the workflow associated with 
processing orders for telecommunication services by providing a focal point for the 
various organizations within the telecommunications company (Gabbita et al.: col. 1, 
lines 46-64). Automation of business processes carried out substantially or entirely on 
computer systems, improve workflow management since the computer systems can 
coordinate all of the tasks and activities, monitor the activities for task completion, and 
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maintain accountability for task completion, therefore, incorporating workflow technology 
helps companies reduce cost and improve efficiency. 

- [Claim 2] the step of defining reference data, the reference data being 
information that is to be made available to the performers of the activity state 
(Barkley: col. 6, lines 35-41, Barkley teaches each role has access to stored 
documents). 

- [Claim 3] the reference data is made exclusively available to the performers 
of the activity state (Barkley: col. 5, lines 20-31, Barkley teaches a role has 
authority and responsibility, therefore, permission(s) associated with that role 
grants access to a resource.). 

- [Claim 4] the reference data is also made available to performers of a second 
activity state (Barkley: col. 6, line 63 through to col. 7, line 37, Barkley 
teaches parallel routings where users are assigned unique roles and perform 
their respective task with the information concurrently.). 

- [Claim 7] receiving an event (Barkley: col. 4 t lines 9-29, Barkley teaches a 
business process can be partitioned into a sequential or parallel routing 
segment that has one or more activities. The workflow management system 
enacts each segment in the order specified by the process definition.); 

- causing a business process object to transition to an activity state 
corresponding to the event, wherein the activity state includes a data 
structure that comprises business process object reference data (Barkley: col. 
4, lines 48-55, col. 5, lines 5-8, 32-36, and 45 through to col. 6, line 5, and col. 
6, lines 23-41, Barkley teaches a business process to be automated is 
partitioned into a sequence of sequential routing segments and parallel 
routing segments where a sequential routing segment has one or more 
activities which must proceed in a strictly sequential manner and a parallel 
routing segment has two or more activities which can proceed in parallel. An 
activity describes a piece of work that forms one logical step within a process 
and is typically the smallest unit of work which is scheduled by a workflow 
engine. The Workflow Management System defines, creates and manages 
the execution of workflows through the use of software, which is able to 
interpret the process definition, interact with workflow participants and, where 
required, invoke the use of information technology tools and applications. 
The workflow specified by a process definition is managed by a workflow 
management system, which enacts each segment in the order specified by 
the process definition. RBAC (Role-Based Access Control) defines 
membership of individuals in groups, i.e. to assign individuals to roles, assign 
permission to roles, and then activate the roles with respect to the process at 
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appropriate points in the sequence; and is used as the basis for a workflow 
management system. Access to objects is managed at a level corresponding 
closely to the organization's structure. Each user is assigned one or more 
"roles", and each "role" is assigned one or more "permissions" that are 
authorized for users in that role. Permissions consist principally of the 
opportunity to perform operations within the activity of the workflow. In this 
connection, "operations" includes "permissions" required to access objects 
within the protected system, such as stored documents, or to perform certain 
activities defined as part of the workflow.); 

- identifying one or more performers for the activity state (Barkley: col. 6, 
lines 23-41, Barkley teaches that in a RBAC system, access to objects is 
managed at a level corresponding closely to the organization's structure. 
Each user is assigned one or more "roles", and each "role" is assigned one or 
more "permissions" that are authorized for users in that role. The operations 
provided for each role correspond to the duties and responsibilities of the 
person having that role in the organization.); 

- creating a task for each performer (Barkley: col. 4, lines 9-29 and col. 6, 
lines 34-41, Barkley teaches the RBAC is used to define membership of 
individuals in groups, i.e. to assign individuals to roles, and then to activate 
the roles with respect to the process at appropriate points in the sequence. 
The subjects can then perform operations as assigned to the roles. In this 
connection, "operations: includes "permissions" required to perform certain 
activities defined as part of the workflow.); 

- completing the task, wherein any changes made to the business process 
reference data during completion of the task are collected (Gabbita et al.: 
col. 30, lines 35-49, Gabbita et al. teach a History File of significant events 
that occur with the system as it pertains to each Service Order. The events 
include transaction processing activities, system access information, and 
administrative manipulation of system data. History File data for Work Steps 
include actual step completion times as well as planned start and finish 
times.); and 

- updating the business process object reference data to incorporate any 
changes that were made during execution of the activity state (Gabbita et 
al.: col. 30, lines 35-49, Gabbita et al. teach a History File of significant events 
that occur with the system as it pertains to each Service Order. The events 
include transaction processing activities, system access information, and 
administrative manipulation of system data. History File data for Work Steps 
include actual step completion times as well as planned start and finish 
times.). 
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- [Claim 8] if the allotted time period to complete a task expires the business 
process object transitions from the activity state (Gabbita et al.: col. 12, 
lines 23-36, Gabbita et al. teach Jeopardy points identify tasks in the Work 
Plan that have deadlines and carry a degree of risk. Should a deadline pass, 
the order is in jeopardy of missing the due date and the Resources assigned 
to unfinished tasks are alerted to this risk by the escalation process. Once 
any Jeopardy point defined for a Work Plan is missed, the escalation process 
places all of the remaining Work Steps for the Work Plan in a Jeopardy state 
and elevates the priority of the Work Plan.). 

- [Claim 9] providing each performer with reference data for the activity state 
(Barkley: col. 6, lines 35-41, Barkley teaches each role has access to stored 
documents.). 

- [Claim 10] the reference data is made exclusively available to the performers 
of the activity state (Barkley: col. 5, lines 20-31, Barkley teaches a role has 
authority and responsibility, therefore, permission(s) associated with that role 
grants access to a resource.). 

- [Claim 11] the reference data is also made available to the performers of a 
second activity state (Barkley: col. 6, line 63 through to col. 7, line 37, Barkley 
teaches parallel routings where users are assigned unique roles and perform 
their respective task with the information concurrently.). 

- [Claim 13] the step of conditionally selecting a transition out of the activity 
state based on the changed reference data (Barkley: col. 7, line 52 through 
to col. 8, line 64, Barkley teaches via an example the role once assigned, 
performs the activity. The successful completion on the activity results in the 
creation of the next activity and removal of the completed role from the 
assignment allowing the new activity to proceed. The new activity receives 
the first completed activity information to complete their role.). 

- [Claim 14] receiving a second event; and applying the second event to the 
activity state only if the event is targeted to the activity state (Barkley: col. 6, 
line 63 through to col. 7, line 37, col. 7, line 52 through to col. 8, line 64, 
Barkley teaches parallel routings where users are assigned unique roles and 
perform their respective task with the information concurrently. The role once 
assigned performs the activity. The successful completion on the activity 
results in the creation of the next activity and removal of the completed role 
from the assignment allowing the new activity to proceed. The new activity 
receives the first completed activity information to complete their role. All 
activities are related to one task.). 
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- [Claim 15] selecting reference data changed by the at least one performer 
and merging it with the associated business process object (Gabbita et al.: 
col. 30, lines 35-49, Gabbita et al. teach a History File of significant events 
that occur with the system as it pertains to each Service Order. The events 
include transaction processing activities, system access information, and 
administrative manipulation of system data. History File data for Work Steps 
include actual step completion times as well as planned start and finish 
times.). 

- [Claim 16] defining state, the state corresponding to either an automated 
step or a human-based step (Gabbita et al.: col. 2, lines 22-43, Gabbita et al. 
teaches Work Plans are used to model business procedures used for 
processing Service Orders. Each Work Plan comprises a plurality of workflow 
steps. Whenever a Service Order is received the appropriate Work Plan to 
process the order is selected based on information contained with the Service 
Order itself. Each workflow step is assigned a Resource and is scheduled for 
completion. Resources are individuals, groups and/or computer systems. 
The examiner interprets workflow step to be either an automated step 
(computer system) or a human-based step (individual or group) as identified 
by the Work Plan.); 

- if the state is defined as an automated step, performing the activity to be 
achieved in the state through the use of an application program to 
complete the step (Barkley: col. 5, lines 50-55, Barkley teaches the Workflow 
Management System defines, creates and manages the execution of 
workflows through the use of software, running on one or more workflow 
engines, which is able to interpret the process definition, interact with 
workflow participants, and, where required, invoke the use of information 
technology tools and applications.), and 

- if the state is defined as a human based step, modeling the state using an 
activity state, wherein one or more performers are employed to complete 
the step (Barkley: col. 4, lines 9-29 and col. 6, lines 34-41, Barkley teaches 
the RBAC is used to define membership of individuals in groups, i.e. to assign 
individuals to roles, and then to activate the roles with respect to the process 
at appropriate points in the sequence. The subjects can then perform 
operations as assigned to the roles. In this connection, "operations: includes 
"permissions" required to perform certain activities defined as part of the 
workflow.). 

- [Claim 17] receiving an event (Barkley: col. 4, lines 9-29, Barkley teaches a 
business process can be partitioned into a sequential or parallel routing 
segment that has one or more activities. The workflow management system 
enacts each segment in the order specified by the process definition.); 
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- causing a business process object to transition to an activity state 
corresponding to the human based event (Barkley: col. 4, lines 48-55, col. 5, 
lines 5-8, 32-36, and 45 through to col. 6, line 5, and col. 6, lines 23-41, 
Barkley teaches a business process to be automated is partitioned into a 
sequence of sequential routing segments and parallel routing segments 
where a sequential routing segment has one or more activities which must 
proceed in a strictly sequential manner and a parallel routing segment has 
two or more activities which can proceed in parallel. An activity describes a 
piece of work that forms one logical step within a process and is typically the 
smallest unit of work which is scheduled by a workflow engine. The Workflow 
Management System defines, creates and manages the execution of 
workflows through the use of software, which is able to interpret the process 
definition, interact with workflow participants and, where required, invoke the 
use of information technology tools and applications. The workflow specified 
by a process definition is managed by a workflow management system, which 
enacts each segment in the order specified by the process definition. RBAC 
(Role-Based Access Control) defines membership of individuals in groups, 
i.e. to assign individuals to roles, assign permission to roles, and then activate 
the roles with respect to the process at appropriate points in the sequence; 
and is used as the basis for a workflow management system. Access to 
objects is managed at a level corresponding closely to the organization's 
structure. Each user is assigned one or more "roles", and each "role" is 
assigned one or more "permissions" that are authorized for users in that role. 
Permissions consist principally of the opportunity to perform operations within 
the activity of the workflow. In this connection, "operations" includes 
"permissions" required to access objects within the protected system, such as 
stored documents, or to perform certain activities defined as part of the 
workflow.); 

- identifying one or more performers for the human based event (Barkley: 
col. 6, lines 23-41, Barkley teaches that in a RBAC system, access to objects 
is managed at a level corresponding closely to the organization's structure. 
Each user is assigned one or more "roles", and each "role" is assigned one or 
more "permissions" that are authorized for users in that role. The operations 
provided for each role correspond to the duties and responsibilities of the 
person having that role in the organization.); and 

- creating a task for each performer, wherein each performer can trigger 
additional events as a result of task operation, as needed (Gabbita et al.: 
col. 1, lines 65-67, col. 2, lines 22-25, lines 36-37, and lines 65-66, col. 3, 
lines 7-10, and col. 11, lines 16-21, Gabbita et al. teach means to coordinate 
all the tasks and activities related to order processing among the various 
entities within the telecommunications company. Work plans are used to 
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model business procedures used for processing Service Orders. Each Work 
Plan comprises a plurality of workflow steps. Business process models are 
depicted as workflow diagrams. Resources are individuals, groups, and/or 
computer systems. Users can log-on to remote workstations attached to a 
company-wide Intranet or the like. Viewing the In-Box is one way in which 
users are notified of the assignment and its associated due date. If a Service 
Order is delayed, users can immediately determine information about the 
delay and take corrective action before it becomes critical. Workflow steps 
can be transferred and re-assigned using the remote workstations. The 
examiner interprets that when a user is working on a Work Plan, they can 
transfers or re re-assigns a workflow step, which will trigger an additional step 
of at least notifying the new designated performer by placing the new work 
step in their In-Box.) . 



11. Claim 6 is rejected under 35 U.S.C. 103(a) as being unpatentable over Barkley 
(U.S. Patent No. 6,088,679) and Gabbita et al. (U.S. Patent 6,349,238) in view of Kiely 
(Kiely, XML: More Than Just A Quick Fix, InformationWeek Online, 8 February 1999 
[GOOGLE]). Barkley and Gabbita et al. disclose a method for incorporating human- 
based activities in business process models but fails to disclose the business process 
model is created using Uniform Modeling Language constructs. Barkley teaches the 
Workflow Management System is a system that defines, creates and manages the 
execution of workflows through the use of software which is able to interpret the process 
definition, interact with the workflow participants and, where required, invoke the use of 
information technology tools and applications (col. 5, lines 50-55). Kiely teaches the 
Uniform Modeling Language as fast becoming the standard means of modeling 
software projects (Para 20). It would have been obvious to one of ordinary skill in the 
art at the time of the applicant's invention to use the Uniform Modeling Language of 
Kiely with the teachings of Barkley and Gabbita et al. because Barkley teaches an 
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improved automation of business processes carried out substantially or entirely on 
computer systems (col. 1, lines 10-15). Time is money to businesses. Software 
specifically designed for a type of application minimizes the time for programming. The 
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a business event. 
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A significant number of companies are re- 
engineering their business to be more effective 
and productive. Consequently, existing 
applications must be modified, and new 
applications must be written. The new 
applications typically run in a distributed and 
heterogeneous environment, performing single 
tasks in parallel, and demanding special 
transaction functionality for the supporting 
environments. Workflow-based applications offer 
this type of capability. In this paper, their 
principal advantages are derived and set in 
context to transaction, object, and CASE 
(computer-assisted software engineering) 
technology. In particular, a method Is proposed 
to develop these workflow-based applications in 
a cohesive and consistent way. 



Business re-engineering is one of the most im- 
portant topics on the agenda of a large number 
of companies. It has been triggered by a changing 
business environment that requires companies to be 
more flexible and to react faster. 1 New processes are 
defined; existing ones are changed or even aban- 
doned. 

These processes are no longer only intraenterprise 
processes, such as claims processing in an insurance 
company or loan processing in a bank. Multiple en- 
terprises are connecting their tasks together in in- 
icrcnlcrprisc processes to more efficiently manage 
their own processes. The order activity in a produc- 
tion planning process for a car company, for exam- 
ple, starts the appropriate order entry process at a 
parts supplier. Companies may even use common 
processes to tie together parts of their various com- 
panies to form virtual companies, as foreseen by niiip 
(National Information Infrastructure Initiative). 2 



Business processes not only deal with customers; in- 
ternal administrative processes are also business pro- 
cesses. A typical example of such an administrative 
process is the handling of an expense account form. 
An employee fills in the proper information; the form 
is routed to the employee's manager for approval and 
then on to the accounting department to disburse the 
appropriate check and mail it to the employee. Back- 
ing up and restoring databases as performed by data- 
base administrators is another administrative process. 

One of the key objectives of the re-engineered bus- 
iness processes is to minimize the time required for 
execution, In a well-defined business process, there- 
fore, all unnecessary tasks have been eliminated, and 
all tasks are performed with the highest degree of 
parallelism possible. These tasks can be performed 
by different people. Coincidentally, different equip- 
ment with different software is used to perform the 
tasks. Thus those business processes are run in a dis- 
tributed and heterogeneous environment. 

Workflow management systems (wfmss) provide the 
foundation for defining and executing business pro- 
cesses. We will refer to applications built according 
to the workflow paradigm as workflow-based appli- 
cations. 

The creation of workflow-based applications needs 
a special development method, which we czWprocess- 
based CASE (computer-assisted software engineer- 
copyright 1997 by International Business Machines Corpora- 
lion. Copying in printed form for private use is permitted with- 
out payment of royalty provided (hat (1) each reproduction b done 
without alteration and (2) ihe Journal reference and IBM copy- 
right notice are included on the lire I page. The title and abstract, 
but no other portions, of ihls paper may be copied or distributed 
royalty free without further permission by computer-based and 
other information-service systems. Permission to republish any 
other portion of this paper must be obtained from the Editor. 
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Figure 1 Evolution of application structures 
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ing). The method we are proposing in this paper pro- 
vides a consistent way of developing this kind of 
application. The metaphor fundamental to this 
method is the two-level programming paradigm of 
workflow technology, in which programming in the 
small is delivered through visual builders, and pro- 
gramming in the large is delivered via business mod- 
eling tools and workflow build time. 

The next section introduces the notion of a workflow- 
based application by revealing the impact of data- 
base and workflow technology on the structure of 
applications. The subsequent section summarizes the 
benefits of workflovv-based applications. Then the fol- 
lowing section sketches some relations andsynergy be- 
tween workflow technology and object technology. The 
section after that outlines an application developer's 
wish list for a development environment that helps to 
efficiently design, implement, and monitor workflow- 
based applications, and the succeeding section provides 
a blueprint of the components of such an environment. 
That section is followed by one showing some aspects 
of testing of workflow-based applications without re- 
quiring the setup of a complex environment, and then 
a simple example of how such an environment could 



work is given. The last section outlines the transaction 
management features of a workflow management sys- 
tem desirable for further enhancing the flexibility of 
workflow-based applications. The paper concludes with 
a summary. 

The notion of workflow-based applications 

Figure L shows the fundamental steps in the evolu- 
tion of the structure of application systems. As de- 
picted in pan 1 of the figure, the first application sys- 
tems built were large monolithical pieces of code with 
some internal structuring. The internal structuring 
reflected the pieces of infrastructure code that had 
to be built by the application developers, in addi- 
tion to the pieces of code that implemented the ac- 
tual logic of the application. 

Removal of data dependency. The lower boxes of 
part 1 reflect some pieces for accessing data. These 
pieces include, for example, the handling of data sets, 
such as openingand closing an account file, perform- 
ing the actual physical input and output operations 
via the appropriate I/O routines provided by the op- 
erating system, such as reading an account record. 
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or interpreting the data retrieved according to some 
inline mapping information, such as the location and 
the type of the account number. 

Any change to the schema of the data, such as the 
addition of a field to a record or a change of access 
path to the data, requires all applications that ac- 
cessed the record to be changed and the data to he 
migrated. Therefore, these applications are data de- 
pendent. 

To reduce data dependency, each application sys- 
tem introduced its own files holding redundant cop- 



Workflow management systems 

support the definition and 
execution of business processes. 



ies of the "same" data with the well-known conse- 
quences of jeopardizing data consistency. 

The management of the information about the data, 
such as which data are maintained and where the 
data are used, is also cumbersome. This situation be- 
came worse over lime with the increasing amount 
of information. 

As a consequence, database management systems 
(DBMSs) were developed. - 1 Their purpose was to sup- 
port the definition and concurrent manipulation of 
data. Many changes to the data schema and access 
paths, for example, can now be done without impact- 
ing the related programs. The body of data becomes 
a property in its own right; it becomes a corporate 
asset. Consequently, the structure of applications 
changed to the structure depicted in part 2 of Fig- 
ure I. 

Removal of Row dependency. The boxes depicted 
in the middle of each of the three parts are the ap- 
plication logic blocks that contain the actual appli- 
cation functions and business algorithms. The top 
boxes in part 1 and part 2 show some pieces that are 
required to put these application logic blocks to- 
gether in a form prescribed by the application. To 
use a banking application as an example, it would 
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include bringing the blocks into the correct sequence 
to first withdraw money from one account and then 
deposit it into another account, or passing the proper 
data from one block to the next so as to pass the 
amount of money to be transferred from the with- 
draw block to the deposit block, or assigning the right 
person to a task based on application-specific cri- 
teria such as the authority of the account owner. 

A change in the assignment of tasks to people, com- 
monly referred to as staff assignment, 4 in the exe- 
cution sequence of the application logic blocks, or 
the addition of a field to be passed between the 
blocks, requires the application to be changed. Ap- 
plications are flow dependent. 

These changes are cumbersome and generally can- 
not be performed fast enough. In addition, the ac- 
tual structure of the business process is not known 
to nonprogrammcrs. This situation becomes worse 
with the increasing demand to adapt to market needs 
that are changing ever faster. 

Workflow management systems were developed to 
help overcome these problems. Their purpose is to 
support the definition and execution of business pro- 
cesses. That means that the definition and execution 
of the appropriate control and data flow, the assign- 
ment of people to tasks, and the invocation of the 
application logic blocks arc externalized. By defini- 
tion, changes to the process can now be done with- 
out impacting the application logic blocks. The pro- 
cess becomes a property in its own right— it becomes 
a corporate asset. 5 The structure of the applications 
changes to the structure depicted in part 3. The ap- 
plication becomes zworkflow-based application con- 
sisting of a model of the underlying business pro- 
cess and a set of (flow-independent) application logic 
blocks." The abstractions of the elementary pieces 
of work in a business process are called activities; the 
concrete realizations of these abstractions at process 
execution time are referred to as activity implemen- 
tations.* The application logic blocks correspond ex- 
actly to these activity implementations in a wrMS 
environment. 

The capability of the workflow management system 
to support the definition and execution of control 
and data flow, the assignment of activities to peo- 
ple, and the invocation of the activity implementa- 
tions associated with such an activity is not limited 
to splitting up large monolithical applications. It al- 
lows the various activities to be distributed to dif- 
ferent computers with different systems. Different 
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systems may mean different operating systems sup- 
ported by the same workflow management system 
or may mean different workflow management sys- 
tems. Workflow-based applications are, therefore, 
by nature distributed, heterogeneous applications. 

The fundamental benefits of workflow- 
based applications 

In this section the following four fundamental ben- 
efits inherent to workflow-based applications are dis- 
cussed: 

• Flexibility in changing the model of the underly- 
ing business process 

• Integration capabilities for even disparate appli- 
cations 

• Reusability of activity implementations and pro- 
cess models 

• Scalability of application development and execu- 
tion 

Flexibility. The first benefit is based on the two-level 
programming paradigm underlying workflow-based 
applications. The specification of all flow relation in- 
formation is, as was already described, separated 
from the specification of the logic of the application 
functions, that is, the algorithmic aspects of the ap- 
plication. This separation allows the model of the 
process underlying the subject applications to change 
without affecting the associated activity implemen- 
tations. It is the predominant reason why enterprises 
arc investing in workflow technology today. 

Integration. The second benefit is based on multi- 
pic features. 

First, the ability of a wfms to persistently store the 
workflow-relaied execution context of each activity 
implementation (that means the containers 4 ) and 
share it between different activities via the supported 
data flow features allows for an integration of ac- 
tivity implementations that is different from the cur- 
rent standard approach of accessing a joint database. 

Second, transaction features tailored toward support 
in WFMS* have been proposed (for example, see Ref- 
erences 7, 8, 9, 10, and 11) to especially allow the 
integration of activity implementations that arc ac- 
cessing different DBMSs into atomic units (in the sense 
of "all or nothing 1 ') or compensation units (in the 
sense of "joint compensation"); sec the last section 
for more details. 
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Third, the heterogeneity feature currently being 
worked on by the Workflow Management Coalition 
(WfMC) ,: and NIHP : strives toward support of cross- 
enterprise business processes. That support means 
that each application part may even be managed by 
a different vendor's \VFMS.The goal is to enable "vir- 
tual enterprises" not only by supporting cross-enter- 
prise sharing of duta based on the STEP (STandard 
for the Exchange of Product definition data) stan- 
dard (for example, see Reference 13), but also to 
share business processes across enterprises and to 
enable inte rope ration of workflow management sys- 
tems. 

Reusability. The third benefit is based on the struc- 
ture of workflow-based applications themselves. As 
elaborated earlier, activity implementations for pro- 
cess models are typically flow- independent and free 
of assumptions about their usage (with the final con- 
sequence that external transaction mechanisms are 
needed; see the last section). Therefore, a particu- 
lar activity implementation can be used in many dif- 
ferent process models. If both the activity implemen- 
tation and the workflow manager comply with the 
wrMC standard for "invoked applications," 12 the ac- 
tivity implementation can ultimately be used in many 
different WFMSs. As a result, the exploitation of work- 
flow technology stimulates reuse of code with activ- 
ity implementations (for proper application logic) 
as the granules of code reuse. Whereas the reuse of 
class libraries, frameworks, parts, and design patterns 
is coupled with object technology (for example, see 
Reference 1 4), reuse based on workflow technology 
is independent of it. 

Furthermore, there is a strong demand for reusing 
process models themselves. For this purpose, many 
WFMSs allow for activity implementations that are 
realized us process models, so-called "subpro- 
cesses," thus enabling top-down and bottom-up mod- 
cling of processes that helps stimulate the reuse of 
process models as subproccsscs. 

Industry consortia such as the Object Management 
Group (OMO) and the Object Definition Alliance 
(ODa), as well as various vendors, are currently de- 
fining reusable components for the purpose of be- 
ing able to construct applications out of prefabricated 
parts. The expectation is that these components will 
eventually be sold as off-the-shelf components. 

The formation of a joint work group of the OMC and 
wfMC indicates that these components will be spec- 
ified in a manner such that they can be used as ac- 
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tivily implementations within business process mod- 
els. This will further help to promote the paradigm 
of workflow-bascd applications. 

Similarly, industry interest groups and vendors are 
in the process of specifying de facto standards for 
models of business processes that apply to partic- 
ular application domains. These process models can 
be reused in particular as subprocesses in enterprise- 
speciflc processes. In this context, it is interesting to 
note that vendors of standard software, SAP with 
R/3** " for example, are currently describing their 
applications via models of business processes, mak- 
ing use of workflow management systems so that the 
application performs according to the process model. 
Workflow-based applications will thus very likely play 
a major role in this area, too. 

Scalability. The fourth benefit of workflow-based ap- 
plications is their scalability in terms of application 
development and application execution. Scalability 
allows workflow-based applications to be used for 
small applications, such as the management of a doc- 
tor's office, and for large applications, such as the 
order process in a manufacturing company involv- 
ing processes of outside suppliers. At first glance, one 
would assume that covering such a broad spectrum 
demands specialized workflow management systems 
that have nothing in common except a few basic 
ideas. However, that is not the case. It seems that 
the development groups of workflow management 
system vendors strive for one system architecture and 
design that caters to the demands of small and large 
applications. 

Application development. The development of work- 
flow-based applications provides scaling through the 
underlying two-level programming paradigm, the 
top-down process modeling capabilities, and the re- 
use of process models and business objects. 

Developing an application in two separate levels, 
first, the development and test of the business pro- 
cess and, second, the development and test of the 
activity implementations, reduces the complexity of 
the application from a design, implementation, and 
testing standpoint. In particular, the parallel devel- 
opment of the activity implementations, made pos- 
sible by the fixed interfaces to the business process, 
provides for a faster development cycle. 

The support of subprocesses allows the top-down de- 
velopment of business processes. First, the high-level 
business process is developed and tested, and then 
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the low- level business processes are developed and 
tested. This sequence facilitates the parallel devel- 
opment of business processes. 

Using business objects and reusable process models 
makes business process development as well as ac- 
tivity implementation development easier. 

Application execution. Scaling of the application dur- 
ing execution is facilitated through the workflow 
manager's execution environment: subprocesses can 



Scalability allows workflow-based 
applications to be used for both 
small and large applications. 



be executed on different servers; workload balanc- 
ing supports exploitation of the available resources; 
dynamic invocation of activity implementations (even 
on remote processors) provides flexibility in execut- 
ing activity implementations; and distribution of 
work items allows the assignment of users to servers 
to be balanced. 

Objects can benefit from workflows 

Enterprises are investing today in object technology 
to improve the productivity of their programmers 
and to enable even non-data-processing profession- 
als to build applications via visual builders (described 
in a later section). Here we discuss some of the ben- 
efits object technology might gain from workflow 
technology and how workflow-based applications can 
be built with objects. Note that vendors of standard 
software (like SAH) are also combining object tech* 
nology and workflow technology (for example, see 
References 15 and 16). 

Flow-independent objects. One of the underpinnings 
of object technology is the insight that robustness of 
a system is normally achieved by encapsulating things 
that might become subject to changes. So, for ex- 
ample, if the order in which operations arc to be per- 
formed can change, or if operations can be added 
or removed, the guidelines of object technology con- 
sequently recommend a dedicated control object. 
That control object encapsulates the scheduling of 
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various operations. Thus, to achieve robustness via 
encapsulation, not only behavior and data must be 
I ;iken into account (what is usually done), but also 
'"ordering." 

IT ihc last proposition is ignored, following the en- 
capsulation paradigm lends to hide fragments of the 
proper business processes in the implementations of 
the objects.' 7 In this situation not only the objects 
themselves become flow-dependent, but transitively 
so does each application reusing these objects. In ad- 
dition, the business processes (being an asset by 
themselves) are only pa rtially described explicitly and 
externalized to a broader community. In contrast, 
implementing objects in such a way that they become 
How-independent will result in component-based ap- 
plications that are much more flexible. 

Scripting and objects. Building flow-independent 
business objects will enforce a clear separation of 
the more stable behavior of the business objects from 
the more dynamic behavior of the business processes. 
A business process explicitly describes the rules of 
how, when, and by whom the services provided by 
the various objects are exploited. An activity imple- 
mentation within a business process maybe directly 
realized by invoking a method of an object. 

When the statics of a business split from its dynam- 
ics, the interaction between business objects is de- 
fined by the process model. The process model may 
be perceived as a script prescribing the use of bus- 
iness objects to reach particular business goals. At 
run time, the workflow management system will man- 
age the How of control and data between the bus- 
iness objects, will establish transaction boundaries 
around them as defined in the script, and will make 
certain that the proper organizational units of the 
enterprise become responsible for utilizing the ser- 
vices provided by the various business objects. Note 
that languages like C+ + follow a similar philoso- 
phy. A program consists of objects and procedural 
elements explicitly describing the control flow be- 
tween the method invocations of the objects. 

It is important to note that we do not consider work- 
flows as a substitute for scripting languages such as 
Ri:.\x. w LotusScript 'V* or Visual Basic**/ 1 These 
languages can be considered as lightweight scripting 
languages very well-suited for composing desktop ap- 
plications for a single end user, perhaps done by the 
end user. Defining a workflow can be considered as 
Iwaxyweighi scripting suitable for composing appli- 
cations requiring the collaboration of multiple peo- 
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pie distributed throughout an enterprise. Heavy- 
weight scripting adds such features as parallelism, 
heterogeneity, distribution, and context-dependency 
to the notion of scripting. The implementation over- 
head inherent in these features is the reason why we 
call this kind of scripting "heavyweight" and why wc 
think two different categories of scripting have a right 
to exist. 

Workflows in object-oriented analysis and design. 
Object technology provides many techniques to cap- 
ture the dynamic behavior of an application, for ex- 
ample, collaboration graphs, event flows, timing di- 
agrams, and interaction diagrams. At an abstract 
level, they have the structure depicted in Figure 2, 
which we call a message flow diagram. Basically, such 
adiagram describes the control flow between method 
invocations of the participating objects. 

Reference 21 points out, based on this insight, thai 
two principally different structures of such diagrams 
can be observed (see Figure 3). Forks represent cen- 
tralizing responsibilities, which means that a single 
object represents the global control and data flow. 
The other objects mainly provide utilities. Such a 
structure is preferred by workflow purists. Stain rep- 
resent delegating responsibilities, which means that 
each object knows a few other objects and how to 
exploit them. Thus, each object is responsible for the 
local control and data flow and is thus flow-depen- 
dent. Many object purists can be found who prefer 
this structure. Our proposition that robustness 
achieved via encapsulation must not only regard be- 
havior and data, but also ordering, is represented by 
forks that typically encapsulate ordering. In contrast, 
stairs express an assumed stability of ordering. It is 
obvious that fork and stair structures have to be used 
in combination to yield a stable and robust structure. 

One of the special strengths of workflow technology 
is facilitating modifications for operation orders in 
an easy manner. Thus, it is only natural to exploit 
workflow technology' for the implementation of fork 
structures, that is, for encapsulating the ordering of 
operations. Simply. Ihc controlling object itself be- 
comes an instance of a process model that in turn 
describes the control and data flow between the af- 
fected objects. 

For this purpose, each method invocation stimulated 
by the control object becomes an activity in the pro- 
cess model, which finally represents Ihc control ob- 
ject. Thus, if the method m of object o is invoked, 
oju ( ) is an activity of this process model. The con- 
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Figure 2 Message flow diagram 



i ; 



USED OBJECTS 

OBJECT. 1 OBJECT J 08JECT.3 



V 



OBJECT n 







<MESSASE> 


l 














Figure 3 Forks and stairs 
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trol connectors are prescribed by the time order in 
which messages are sent according to the message 
flow diagram. If ni I is sent to o\ and ml is sent to 
o2 and no other message is sent to any other object 
in between, the flow of control is from o 1 ,m I ( ) to 
ol.mli ). Based on the structure of message flow 
diagrams, no parallelism is exploited in the process 
model derived by this simple algorithm. Typically a 
design phase needs to be conducted to establish a 
more sophisticated process model. 



At run time, the wfms will instantiate this process 
model, resulting in an instance of the control object. 
By definition, there will be no implementation of the 
control object in the classical sense, for example, in 
C+ + : the implementation consists of the process 
model, which is interpreted on a per instance basis 
by the WFMS. Consequently, changes to the process 
model will immediately affect the implementation 
of the corresponding control objects instantiated af- 
ter the changes. 
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A method has been proposed in Reference 6 for an- 
alyzing a message flow diagram in order to divide it 
into a collection of subdiagrams, each of which is ei- 
ther a fork structure or a stair structure. Fork struc- 
tures can be transformed into skeletons of process 
models in a straightforward manner. Stair structures 
are natural candidates for modularization; that is, 
they can be realized as programs or as subprocesses. 

Application developer's wish list 

The development of workflow-based applications can 
be facilitated by a new approach that helps appli- 
cation developers in the design, implementation, and 
testing of those applications. We call this approach 
process-based case to indicate that the goal of the 
proposed CASE method is to create applications that 
are workflow-based, thus implying that the under- 
lying business process is externalized and managed 
by a workflow management system. This approach 
is different from the notion of process-centered CASE, 
where processes are used to develop applications and 
coordinate development teams." In fact, process- 
centered case could also be applied to process-based 

CASE. 

First, the development of the applications should be 
supported with the set of new and evolving program- 
ming paradigms, such as visual programming, the 
construction from parts, the usage of business ob- 
jects, binary code reuse, object orientation, and, by 
definition, the exploitation of workflow. 

• Visual programming supports the development of 
programs that are no longer performed by writing 
statements in a programming language. The pro- 
gram is constructed (1) by creating the advanced 
graphical user interface of the program by draw- 
ing the screen layouts on the screen, and (2) by 
visually assembling and connecting parts to define 
the behavior of the program. 

. • Construction of parts is a technology to build ap- 
plications from existing, reusable software compo- 
nents called pans* The assembly is typically per- 
formed via the composition editor of the visual 
builder. Parts provide a wide range of capabilities, 
from very simple functions through complete, 
highly sophisticated applications. Primitive parts 
can be combined to form more complex compos- 
ite parts. 

• Business objects are becoming increasingly impor- 
tant as granules of reuse. Typical examples may 
be a customer business object or an account bus- 
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iness object. Standardization is underway as shown 
earlier in the third section of this paper. 

* B'utary code reuse is a key factor in the success of 
application development productivity. Source code 
reuse just will not render the productivity increase 
the software industry is looking for. Business ob- 
jects are the main manifestation of this paradigm. 

♦ Workflow allows us to define, execute, and mon- 
itor applications that move the work to be done 
to the desktop of the person responsible for per- 
forming a piece of the overall task. 

Second, the development approach must cater to the 
specific characteristics of workflow-based applica- 
tions. It must support the design, implementation, 
and testing of the distribution aspects of the appli- 
cations, in particular, the parallel execution of tasks. 

Third, it must support openness through compliance 
with appropriate standards, including de facto stan- 
dards such as CORDA (Common Object Request Bro- 
ker Architecture), 24 OLE (Object Linking and Em- 
bedding), 25 WfMC, OpenDoc, 34 and Lotus Notes**. 

Fourth, this development environment must be avail- 
able on a variety of platforms. 

And last, the components of the development envi- 
ronment must be tightly integrated. In particular, 
they must provide a cohesive, seamless, and intui- 
tive end-user interface. 

Development environment blueprint 

The essential components for the proposed environ- 
ment are ( 1 ) a business modeling tool, (2) an object- 
oriented analysis tool, (3) a workflow management 
system, (4) a visual builder, (5) a database manage- 
ment system, (6) a database design tool, and (7) ob- 
ject support. Figure 4 depicts those components that 
arc exposed directly to the user of such a develop- 
ment system. In this section we discuss the compo- 
nents. 

Business modeling. A business modeling tool is one 
of the starting points for developing workflow-based 
applications. It is intended to be used by internal or 
external consultants, organization specialists, or bus- 
iness re-engineering experts. IBM's Business Process 
Modeler, iDS's AKIS** Toolset, Holosofx's Work- 
ftowBPR tool, or UBiS's BON APART** are typical ex- 
amples of this type of tool. Their main focus is on 
allowing the business experts to model processes and 
business objects used within a business process. They 
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Figure 4 Development components 
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typically implement a proprietary methodology to 
describe the business process. For example, the IBM 
Business Process Modeler uses an extension of the 
LOVEM* (Line of Visibility Enterprise Method) 
methodology developed by IBM Canada for re-en- 
ginccring corporations: the ARIS Toolset uses the 
ARIS methodology developed by Scheer. 2 " 

The usual result of such an analysis is a high-level 
description of the business process. On a conceptual 
level, this high-level process describes the business 
actions and their relations, the organizational units 
performing these business actions, and the business 
objects that these business actions are working on. 
The level of detail depends on the significance of a 
particular item in the overall business process. A bus- 
iness object therefore could be a complete database, 
such as the payroll database, or a single column in 
a table, such as a state code used to determine which 
path needs to be taken within the process. 

An important function of business modeling tools 
is to collect metrical information about strategic tar- 
get volumes of business objects and processes. This 
information will be refined later in the development 



process to determine the performance characteris- 
tics of the process us well as the resources, both peo- 
ple and it (information technology) resources, re- 
quired to perform the process. 

In general, the results obtained via the business 
process modeling tool are not directly usable by a 
workflow management system to execute the bus- 
iness processes. They need further refinement in the 
specifications of IT resources, such as programs used 
to perform the activities, the topology of the system, 
etc. This task is performed using the build-time com- 
ponent of the workflow management system. The ap- 
proach is similar to the one taken in the design of 
databases, where it starts with a conceptual design 
that is transformed into a logical design. The con- 
ceptual design, for example, done as an entity- re- 
lationship model, provides an implementation-inde- 
pendent view of the data. This model is then 
translated into a logical design, such as the tables of 
a relational database system, by adding implemen- 
tation-dependent information. 

How the information is handed over to the work- 
flow management system is a matter of coupling the 
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business modeling tool and the workflow manage- 
ment system. One approach is to have a common 
data store. A simpler approach is the generation of 
an interchange format that is imported into the work- 
flow management system. The WfMC is standardiz- 
ing this format to facilitate the interchange of 
process model information between different imple- 
mentations of workflow management systems. Un- 
til this standard is issued, the business modeling tool 
must generate the workflow manager's proprietary 
exchange format, such as the FlowMark Definition 
Language (fdl) of IBM's FlowMark*. The aris Tool- 
set, for example, generates FDL from its process def- 
initions. 

Object-oriented analysis. Another approach to the 
development of workflow-based applications is ob- 
ject-oriented analysis and design. As outlined pre- 
viously, the results of the analysis could be used in 
different ways. It could be used to generate process 
skeletons in the workflow manager's exchange or, if 
available, in a standardized format. It could also pro- 
vide the visual builder with the proper information 
to allow rapid creation of the activity implementa- 
tions. 

Workflow build time. The purpose of the build-time 
component is to allow the user to define the pro- 
cesses in terms of process logic, associated organi- 
zational information, and IT infrastructure required 
to execute the processes. 4 - 5 As pointed out earlier, 
this information may be derived from information 
collected by the Business Modeling Tool or the Ob- 
ject-Oriented Analysis Tool. The definition of the 
information is entered via a graphical end-user in- 
terface. Typically an animated process graph is used 
to help determine the correctness of the process 
graph and the correct invocation of the programs im- 
plementing the system program. Analytical and dis- 
crete simulation help to determine whether the or- 
ganization is capable of handling the workload and 
whether the rr resources are sufficient to cope with 
the system, database, and communications load. 27 

Visual building. A visual builder is a visual program- 
ming tool that can help develop all kinds of appli- 
cations, including mission-critical applications. It al- 
lows a programmer to rapidly prototype and build 
applications with menu bars, entry fields, and icons. 
Programs are written simply by making connections 
between objects and parts. 

Workflow run time. The run-time component of the 
workflow management system controls the execution 
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of process instances. It allows the user to start, ter- 
minate, suspend, and resume processes. It deter- 
mines who should perform a particular activity, puts 
the resulting work item onto the work list of the se- 
lected user(s), schedules the proper program when 
a work item is selected and determines what activ- 
ities come next after one has been completed, and 
records all these actions in an audit trail. 

Process monitoring. Processes must be monitored 
for various reasons: (1) to determine the workload 
of people and take proper action if the workload is 
unevenly distributed, (2) to recognize critical situ- 
ations where work is piling up, and (3) to obtain pro- 
cess statistics. The process statistics are created from 
the audit trail that is automatically written by the 
workflow management system during process exe- 
cution. This information can be used to verify the 
assumptions used during simulation, such as process 
creation rates, path selection probabilities, and ac- 
tivity processing time. 

Schema creation. The business objects identified 
during business modeling or object-oriented anal- 
ysis are the input to conceptual data modeling. They 
represent the local conceptual schema of the appli- 
cation implemented via a business process. In gen- 
eral, these objects form the kernel entities of the en- 
terprise data model and thus provide the basis for 
the creation of an enterprise data model through 
view integration. uw 

The conceptual schema is transferred into a logical 
schema, the schema of the database in which the data 
are stored. Reference 28 outlines the rules for trans- 
ferring an entity-relationship schema into a relational 
schema. 

A physical schema is created from the logical schema 
by choosing specific storage structures and access 
paths to achieve optimum performance for the var- 
ious applications. Input to the physical schema de- 
sign consists of the transaction load and the data- 
base load. Both pieces of data can be derived from 
information collected during business modeling, 
workflow definition, and application building. 77 

Database monitoring. The activities in the databases 
must be monitored to detect performance bottle- 
necks. Monitoring could trigger modifications of the 
database schemes. It is also conceivable that it may 
impact the structure of the business processes. 
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Figure 5 Verification phases 
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Verification of workf low-based applications 

The underlying business process of non-workflow- 
based applications is, as outlined previously, deeply 
buried in the application itself. That means the bus- 
iness process and the application logic need to be 
tested together. In workflow-based applications, the 
business process and the programs implementing the 
activities are described separately. 

Testing workflow-based applications, therefore, is 
much simpler, since to a large extent the testing of 
the business process can be done independently of 
the testing of the activity implementations. In fact, 
the testing of the business process can be done be- 
fore the actual implementation of the application 
functions starts. As soon as testing of the business 
process is completed, the interfaces for the control 
and most of the data relevant to the data flow are 
defined. 

The verification of workflow-based applications is 
performed in three phases, as shown in Figure 5. The 
first step checks the process models for correctness, 
1 1 includes checking to see whether the process struc- 
ture, the invocation of programs, and the distribu- 
tion of work are correct. 

What needs to be checked and what can be checked 
for correctness of the process structure depends on 



the underlying process meta-model. 2 " In the case of 
IBM FlowMark, for example, no checks need to be 
performed for loops since the process graph is a di- 
rected, acyclic graph. But two basic items always need 
to be checked. First, the passing of data from one 
activity to a subsequent activity must be correct and 
complete. Incomplete data lead to an incorrect eval- 
uation of transition conditioas, resulting in incorrect 
control flow and the passing of incorrect data to in- 
voked programs or subprocesses. This item is par- 
ticularly important for activities where a field in the 
input container is the target of multiple data con- 
nectors. Second, the transition, exit, and start con- 
ditions must be semantically correct. 

The invocation of programs includes not only de- 
fining the proper invocation mechanism, but also 
properly passing data to the program and returning 
the appropriate data. 

A staff assignment identifies the set of people who 
must perform the appropriate task for each activity. 
Therefore, checking the correct work distribution in- 
volves not only seeing whether work is assigned to 
the right person, but also obtaining a first hint of 
whether the work is distributed properly. 

IBM FlowMark, for example, uses the technique of 
animation to help the process modeler perform this 
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task.** 1 h offers iwo modes, process debugging and 
ihc regression lest, fn the process debugging mode, 
the user navigates through ilie process model step 
by step. In the regression test mode, a stored script 
is automatically executed. The execution of the ap- 
propriate programs is simulated by displaying the in- 
put to be passed to the program and allowing the 
user to (ill in the data to he returned by the program; 
thus, the programs must not have been implemented. 
The advantages of the animation arc: (I) the iden- 
tical presentation of the process model is used for 
modeling and debugging. (2) the visualization of con- 
trol and data How as well as the status display of ac- 
tivities allow design errors to be easily recognized, 
(3) animation can he done at any time, even if the 
process mode! is syntactically and semanlically in- 
correct. (4) the work list of the process participants 
is visualized, and (5) the interaction in the process 
debugging mode can be stored to be used in regres- 
sion test mode. 

In a second step, the process models are checked to 
sec whether the organization as well as the it infra- 
structure is capable of supporting the number of ex- 
pected process instances. The technique used for this 
phase is simulation: analytical and discrete. 

Simulation is based on metrical information that is 
collected for the process and the activity level and 
is mostly provided by the business analyst. The pro- 
cess -lev el information includes the number of pro- 
cesses started, the probability that a certain branch 
is taken in the process, the probability that an ac- 
tivity is repeated, and the size of the process input 
and output containers. For the activity, it includes 
process-related information. such as the average time 
required to perform the activity, including idle and 
wail time. 

Analytical simulation is used to calculate the required 
people and computer resources. If this turns out to 
be insufficient, any further analysis is superfluous. 
The sufficiency of computer resources is evaluated 
by determining the CTU load on servers and clients, 
the network traffic caused by serve r-to-server com- 
munication and data passed from one activity to the 
next, and the transaction load on the database and 
the transaction processing (TP) monitors. People re- 
sources are calculated by determining the amount 
of time required to perform the activities. The in- 
formation derived for a process is then combined 
with the resource information derived from other 
processes. 
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Discrete simulation is used to determine the impact 
of multiple process iastances competing for the same 
resources. Input to the simulation consist of scenar- 
ios describing which process models should he used 
in the simulation. The simulation component uses 
this information to drive the navigation engine of 
the workflow manager with the proper requests, such 
as process start and activity completion. The results 
are written to a file that serves as input to create the 
simulation results. Typical results arc the probabil- 
ity distribution of process execution time and trans- 
action rates. 

The results of analytical and discrete simulation can 
be used to tunc the accessed databases. Using the 
activity invocation rales and the database accesses 
of the activity implementations, one can determine 
the number and types of structured query language 
(SOi.) calls against each database. This information 
and the current or estimated size of the databases 
provides sufficient input to the physical database de- 
signer to determine the proper database character- 
istics. Furthermore, it allows a user to determine how 
the size of the database changes over time. Collect- 
ing additional information, such as the distribution 
of keys, allows, for example, the detection of hot spots 
in tables. 

The process performance monitor, by analyzing the 
audit trail, helps to obtain in forma I ion relevant to 
the process performance, such as the average pro- 
cess duration, idle time for activities, or excessive no- 
tifications when work is not performed in a timely 
manner. 

A sample scenario 

This section discusses some of the components of 
the development environment in more detail and 
outlines how those components could collaborate. 
IBM products have been selected for purposes of il- 
lustration. The components being explored further 
are the business modeling tool, the build-time com- 
ponent of the workflow management system, and the 
visual builder. The corresponding products are the 
inM Business Process Modeler, FlowtvTark, and Vi- 
sualAge C+ + *, respectively. 

A simple loan process is used as a guide through the 
various components. The loan process starts when 
a customer contacts the bank and finishes when the 
customer receives the appropriate response from the 
bank, cither a denial of the loan or the granting of 
the loan. 
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Business modeling tool. The design of a business 
process can start, as outlined earlier, with a business 
modeling tool. The IBM Business Process Modeler 
implements an extended version of the IBM LOVEM 
methodology, lovem focuses on the interactions be- 
tween the customer and the company. All informa- 
tion is captured via a graphical editor that supports 
the creation of two sets of diagrams: hierarchical 
structure diagrams and line of visibility charts. Hi-' 
erarchical structure diagrams provide a hierarchical 
grouping of all relevant elements, such as processes, 
critical success factors, computer programs, organi- 
zational units, opportunity areas, problem areas, and 
line of visibility charts. 

There are four different types of line of visibility 
charts (LOVC). The architecture LOVC(ALOVC) pro- 
vides an overall view of what the company does, to- 
gether with the essential customers and the sequence 
of business processes. The job lovc (jlovc) shows 
all activities of a job and provides the base for an- 
alyzing the efficiency of job performance. The log- 
ical lovc (llovc) provides a refinement of the 
alovc and shows the data flow between processes 
and subprocesses. The physical lovc (PLOVC) shows 
the activities within a business process and how they 
are performed by connecting activities to other ac- 
tivities or to document storage, office systems, and 
computer systems, for example. 

The charts are organized into horizontal areas, called 
bands. In llovo, a band represents a business func- 
tion within the company, such as personnel. It shows 
what processes are performed by each function and 
the relations between the processes in the form of 
data flows, which represent data that are generated 
from or required by the process. In PLOVG; and 
J LO ves, a band represents organizational units and 
contains for each organizational unit the activities, 
tasks, systems, critical success factors, and other as- 
pects of a business process and the relations between 
those items in the form of information flows. Infor- 
mation flows represent the flow of information, but 
also of goods and controls. 

Figure 6 shows the PLOVC of the loan process. The 
horizontal bands represent the parlies involved in 
the process: the customer, the loan officer, and the 
loan supervisor. The line between the customer and 
the company is called the line of visibility. The man- 
ual and automation bands arc used to describe how 
a particular activity is supported. When the activity 
is in the manual band, it is performed manually; when 
in the automation band, it is completely performed 



114 LEYMANN AND ROLLER 



r" 

by a computer program; when on the line, it is per- 
formed by a computer system that interacts with the 
user. The system shown in the figure is used to col- 
lect loan information for a customer. Based on the 
amount of money involved, an assessment must be 
made by the loan supervisor. Finally, the customer 
receives a loan contract or rejection letter. 

Workflow build time. The business modeling infor- 
mation must now be made available to the workflow 
management system. As pointed out in the earlier 
subsection on business modeling, it is done via an 
interchange format. The business modeling tool con- 
verts the PLOVC of the loan process into FlowMark 
Definition Language, which is then imported into 
FlowMark. This process skeleton must then be en- 
riched with information required during process ex- 
ecution, such as program names, staff resolution ex- 
pressions, and data structures and data connectors. 
This type of information, which is related to infor- 
mation technology, is not collected during business 
modeling. The amount of information to be added 
depends on the amount and granularity of the in- 
formation collected by the modeling tool. Because 
the activities specified with the business modeling 
tool are generally quite coarse-grained, as is the case 
with the IBM Business Process Modeler, they often 
need to be replaced by subprocesses or a set of ac- 
tivities. Figure 7 shows the loan process after mak- 
ing these modifications with the FlowMark process 
model editor. The single system used in the plovc 
for managing loan information has been split into 
multiple smaller programs. The activity "CollectCus- 
tomerlnformation" obtains the customer number. 
If the customer is new, all customer information, such 
as the address, is collected in the activity "Collect- 
CustomerData." The next step, common again for 
all customers, is the collection of credit information, 
such as the amount of credit. 

1 1 should be noted that the program could have been 
implemented as one large program. The decision to 
break up the program has been guided by the desire 
to extract control and data flow, in the spirit of work- 
flow, to make future changes simpler. The one pos- 
sible disadvantage is the amount of time required 
by Ihe workflow manager to navigate through the 
process graph, and it can be eliminated by compil- 
ing pans of the process graph. ' 1 Note explicitly that 
this function is not part of the delivered FlowMark 
product. 

When the credit amount is small, and the customer 
risk factor is low, the loan is accepted right away, 
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Figure 6 PLOVC of loan application 
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and the activity "CreateAcceptanceLetter" is started 
automatically. In the other case, as already shown 
in the plovc, management approval must be ob- 
tained. On the basis of what management decides, 
the loan is cither granted or denied. 

Testing of the application is performed using the an- 
imation facility of FlowMark, as described in the pre- 
vious section. 

Visual builder. A visual builder, discussed earlier, 
is the preferred tool for constructing activity imple- 
mentations. More information about IBM Visual Age 
can be found in References 23 and 32. 

Visual builders allow applications to be constructed 
from existing, reusable software components called 
pans. Parts are either visual or nanvisuaL Visual parts 
allow an application developer to easily construct so- 
phisticated graphical end-user interfaces; nonvisual 



parts provide programming constructs such as ac- 
cessing a database or maintaining a list of text strings. 

A part in Visual Age C++, for example, is a soft- 
ware object implemented as a C++ class that sup- 
ports a simple, standardized protocol. This protocol 
supports the interconnection of parts to form higher- 
function parts or entire applications. The part inter- 
face is composed of three distinct features: attributes, 
actions, and events. These features correspond to a 
natural way of viewing parts (and objects in general) 
in terms of what properties (attributes) they have, 
what behaviors (actions) they can perform, and what 
unsolicited information (events) they can provide to 
other parts. 

The construction of the application is via the com- 
position editor of the visual builder. The editor pro- 
vides the capability to create the views for the ap- 
plication, to select the parts that implement the logic, 
and to make connections between the parts. 
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Figure 7 Loan process 




The workflow management system provides an ap- 
plication interface so that the activity implementa- 
tion can access the input and output containers of 
the activity. The construction of workflow-based ap- 
plications via visual builders Ls simplified through 
nonvisuul parts for the input and output containers 
thai wrap the latter. Reference 33 shows a method 
for creating those parts from the container structures. 
Figure 8 illustrates the construction of the program 
that implements the loan data collection activity in 
the loan process. The window for the composition 
editor shows two data entry parts for displaying the 
customer's first name and last name and two data 
entry parts for entering the credit amount and the 
risk factor. The two nonvisual parts reflect the input 
and output containers of the activity. The arrows be- 
tween two parts indicate that the change of one part 
attribute should be propagated to the attribute of 
another part. The arrows between the input con- 
tainer part and the first name and last name fields 
cause the fields on the screen to be filled with the 
appropriate field from the input container. The ar- 



row between the address and the credit amount fields 
and the output container causes the address and 
credit amount fields to be put into the activities out- 
put container. The arrows between the input and the 
output container part cause the first name and the 
last name attribute of the input container part to be 
copied to the output container part. 

Another application programming interface stan- 
dardized by the workflow management coalition is 
the work list handler application programming in- 
terface. This interface allows application develop- 
ers to replace the workflow manager's standard in- 
terface for managing work lists, starting work items, 
and starting, terminating, and suspending processes 
with a custom -designed interface. The visual builder 
can facilitate the development of these interfaces by 
using parts that wrap the work list handler interface. 

Further integration points between the visual builder 
and the build-time facility of the workflow manager 
are conceivable. For example, honoring each oth- 
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Figure 6 Loan data collection 
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er's drag and drop procedure would allow an activ- 
ity to be dropped on the icon of the visual builder, 
which automatically opens the composition editor 
and puts the appropriate input and output container 
parts on the surface. 

Transaction management for workflow- 
based applications 

Activity implementations can be not only transac- 
tional programs, or classical transactions, but also 
nontransactional programs. For historical reasons, 
transactions as activity implementations frequently 
appear when the encompassing process model rep- 
resents one of (he core business processes (order en- 
try, etc.) of an enterprise, and nontransactional ac- 
tivity implementations are frequently found within 
support processes (t ravel expense accounts, etc). To- 
day it can be observed that many workflows contain 
a mixture of transactional and nontransactional ac- 
tivity implementations. In this respect, wfmss are ve- 



hicles to connect the world of transactions and the 
world of nontransactional programs. The corre- 
sponding programs are "pasted together** unham- 
pered; they are only restricted by business processes 
that prescribe the way in which the enterprise per- 
forms its businesses. 

When the sophistication of an enterprise in exploit- 
ing workflow technology increases, the requirement 
for supporting the definition of work units within 
workflows appears. The exploiters of a WFMS sud- 
denly ask for advanced transaction paradigms that 
relate to their business processes; they call a busi- 
ness process that makes use of advanced transaction 
features a business transaction or an extended trans- 
action. First, it encompasses some transactions in the 
classical sense and combines them with nontransac- 
tional programs, thus extending the scope of tradi- 
tional transaction processing. Second, it groups both 
classical transactions as well as nontransactional pro- 
grams together into a unit of work that reflects the 
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semantics and behavior of their business processes, 
thus extending the classical transaction paradigm. 

Note that most of the features outlined in this sec- 
tion are not available in commercial systems. Because 
of the relevance sketched earlier, we included this 
subject as an outlook to possible extensions of some 
commercial systems. 

A brief sketch of transaction models. For the read- 
er's convenience, we provide a brief taxonomy of 
transaction models based on the duration of the un- 
derlying unit of work. More details on transaction 
models can be found in References 34 and 35. 

The fundamental concept in this area is the acid par* 
adigm, which enforces the collection of operations 
to behave as follows: 

• Either all of them are applied to the system or none 
of them at all (Atomicity). 

• They lead to a new valid state of the system (con- 
sistency). 

• They do not affect (until explicitly made visible) 
operations outside the collection (/solation). 

• lliey are not undone because of any later system 
failure (durability). 

Tremendous work has been performed in the past 
to figure out how the structure and behavior of units 
of work correlate with their average duration. As a 
result, different transaction models have been pro- 
posed. 

What is traditionally subsumed under the notion of 
a transaction is a flat ACIDie unit of work with a du- 
ration of about a second. Typical application areas 
for which this notion of a transaction is best suited 
arc telephone switching, flight reservations, or ac- 
counts handling. Units of work that last for tenths 
of a second when using the flat acid paradigm (like 
an order entry application) resulted in the invention 
of a transaction model (close-nested transaction) that 
allows structuring the overall transaction as a tree 
of subtraasactioas. thus improving parallelism within 
the encompassing unit of work and enhancing its 
overall response time. When huge collections of data 
items have to be manipulated, as in batch updates, 
durations between minutes and hours are found. In 
this situation, ACiDicity results in inappropriate con- 
currency and recover) 1 behavior that means backing 
out all modifications if the last manipulation fails. 
That led to techniques like minibatches and save- 
pointing. Incidentally, these techniques require spe- 
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cial programming by the application programmer, 
such as persistently tracking the state of the trans- 
action. They are, therefore, not suitable in more com- 
plicated applications such as trip reservation systems 
where multiple databases might be accessed and op- 
erations can only be undone scmantically by invok- 
ing special compensation actions. Transaction mod- 
els such as open-nested transactions, which assume 
a manual invocation of compensation, or those such 
as Sagas, which support system-invoked compensa- 
tion, circumvent such restrictions. When units of 
work last for days, weeks, or even much longer, an 
appropriate transaction model must deal with 
(planned and unplanned) system shutdowns with- 
out losing control of the boundary of the unit of work, 
must facilitate partial backout, or must cope with dif- 
ferent users cooperating in the unit of work. The 
compensation spheres transaction model to be de- 
scribed shortly is targeted toward these conditions. 

Two categories of transaction functions. When an- 
alyzing the exploitation of workflow technology with 
respect to extended transaction processing, the fol- 
lowing two independent categories of features can 
be identified. 

• The WFMS should allow for coupling activities of 
business processes with respect to their semantic 
success. An activity is successfully completed se- 
mantically if the work has been finished as it was 
intended by the process modeler. An activity such 
as sending an e-mail note, for example, has suc- 
cessfully completed semantical ly when the note has 
been written and sent. If the work associated with 
an activity cannot be successfully completed se- 
mantically, or when the results produced by a col- 
lection of activities are detected to be incorrect, 
the wfms should undo the already-processed cou- 
pled activities and start the affected parts of the 
business process again. Basically, this is the require- 
ment for a compensation-based partial backward 
recovery facility, which is referred to as compen- 
sation spheres. Work is undone either by automat- 
ically deriving the business process representing 
the reverse execution of the part to be undone or 
by starting a predefined business process to repair 
the situation as described below. 

• The wfms should allow for coupling transactional 
activities, meaning activity implementations that 
represent transactions in the classical sense, with 
respect to their transactional outcome. If one of 
the transactions fails (in the sense of the ACID par- 
adigm), the whole collection must be aborted. Ba- 
sically, this requires the ability to declare the ato- 
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Figure 9 Compensation spheres 




micity of collections of activities (via an atomic 
commit protocol, or via close-nested transactions, 
etc.). Such collections are referred to as atomic 
spheres. A wfms can manage an atomic sphere by 
dynamically creating a common transactional con* 
text when entering the atomic sphere and initiat- 
ing the atomic commit protocol for leaving the 
atomic sphere (see discussion on atomic spheres 
below). 

Compensation spheres. It is the nature of business 
processes that activities are generally long running 
(especially in tolerating system shutdowns) and must 
be thus interruptible, and that they often external- 
ize intermediate results. Obviously, the same is true 
for business processes themselves. Furthermore, a 
business process usually contains collections of ac- 
tivities that are semantically coupled in the sense that 
cither all coupled activities must be performed suc- 
cessfully or the work associated with the activities 
must be backed out to allow the business process to 
continue correctly. In this context, the usual trans- 
action models (generally realized via mechanisms 
like locking, etc.) obviously do not apply. 

A transaction model, called compensation spheres, 
suitable for coping with these requirements has been 
introduced in Reference 9, and the reader is referred 
to that publication for in-depth details. A compen- 
sation sphere is any collection of activities of a pro- 
cess model such that finally either all activities must 



have run successfully, or all activities must have been 
compensated. An activity that has not run is consid- 
ered to be compensated via NOP (no operation, Le., 
nothing is performed); that means in practice only 
the activities of the compensation sphere that were 
activated are physically compensated. Furthermore, 
each activity within a compensation sphere or the 
whole compensation sphere itself is associated with 
an activity called its compensating activity. A com- 
pensating activity might be a program or again a pro- 
cess model. The basic mode of undoing a compen- 
sation sphere is to automatically schedule the 
compensating activities of all activities within the 
sphere in an order that is the "reverse" of the order 
in which the proper activities of the compensation 
sphere have run. Of course, staff resolution does also 
apply to the scheduling of compensating activities. 

Figure 9 shows a process model for trip reservations. 
After the client plans the itinerary, it is submitted 
to travel agents who will try to make the correspond- 
ing reservations for hotel rooms, rental cars, and 
flights. To speed up the reservation process, these 
activities can be worked on in parallel by different 
people. If all reservations have been made, the re- 
sulting schedule is printed and sent to the client. If 
one of the travel agents fails to make an appropri- 
ate reservation (for example, there is no hotel room 
available for part of the itinerary), compensating ac- 
tivities are scheduled to cancel the reservations al- 
ready made. 
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Many different parameters affect actual behavior 
when backing out a compensation sphere. For ex- 
ample, you can specify whether compensation should 
be pe rformed and whelher work within affected pro- 
cess brunch (es) should continue at the entry poi nts 



Writing components without any 
assumptions on transaction 
boundaries will enhance 
their reusability. 



of the compensation spheres, whether some admin- 
istnitivc actions have to take place, or whether the 
control flow simply has to continue at the entry points 
of the compensation spheres without performing any 
compensation. Furthermore, compensation spheres 
can become a target of cascading backouts. and hack* 
out is not only performed in a "discrete" manner by 
running the compensating activities associated with 
the proper activities, but also in an "integral" man- 
ner by simply running a compensating activity (which 
can again l>c defined as a process model) (hat is di- 
rectly associated with the affected compensation 
sphere itself. 

Compensation spheres will provide tremendous ben- 
efits from a cost and re-engineering point of view in 
automating compensation. Many enterprises have 
special departments completely dedicated to com- 
pensation. When erroneous situations arc detected, 
members of these departments are informed., and 
they use compensation techniques to manually re- 
pair the broken resources. Long-running transactions 
will typically he modeled as compensation spheres. 

Atomic spheres. As was described in the third sec- 
tion, activity implementations are canonical candi- 
dates for reuse. It is a well-known proposition from 
software engineering that components built for re- 
use should have weak couplings. In other words, the 
number and complexity of connect ions between such 
components should be minimized. The following ex- 
ample demonstrates this const mint for an activity inv 
plemcniation dealing with recoverable resources. Be- 
cause it is striving for a high degree of reusability, 
it consequently must not assume the management 
of any transaction boundaries. In workflow-bascd ap* 

120 t-nruvw am) aoutR 



plications, it must, therefore, he possible to estab- 
lish transaction boundaries outside of the activity im- 
plementation, 

Let us assume two activity implementations, one of 
which withdraws an amount from a particular 
ACCOUNT, the other DEPOSITS an amount to an 
ACCOUNT. Note that this could be nicely imple- 
mented as two methods of an account business ob- 
ject. Since a customer may sometimes wish to put 
money into his or her account, or sometimes wish 
to withdraw money from the account, it is seductive 
for the implcmeiucr of the DEPOSIT as well as the 
wi thdraw activity implementation to establish a 
separate transaction boundary that will com mil or 
roll back the performed work. The transfer of money 
from one account to another could now reuse both 
the DEPOSIT as well as the withdraw activity im- 
plementation by invoking withdraw for the first 
account and DEPOSIT for the second. It may happen 
by accident that the withdraw activity implemen- 
tation commits, but DEPOSIT does not leave the over- 
all "transaction" in a consistent state. This reveals 
the necessity of being able to establish transaction 
boundaries separate from the activity implementa- 
tions. It is the wfms that could issue independent 
commit requests for withdraw and deposit in the 
first scenario but could issue a "global com m if in 
the second scenario. 

Writing components without any assumptions on 
transaction boundaries will enhance their reusabil- 
ity. This observation is reflected in OMOs Object 
Transaction framework, * which provides access to 
transaction managers and resource managers. It al- 
lows WFMSs to manage transaction boundaries. For 
that purpose we introduce the concept of anatomic 
splutnu An atomic sphere is a set of activities each 
of which is "transactional" in the sense that they ac- 
cess recoverable resources. Furthermore, the con- 
trol flow between two transactional activities of an 
atomic sphere must not leave the atomic sphere and 
enter it again at a later point in time. 'Che wfms will 
make sure at run lime that either all activities that 
have run within the atomic sphere are committed or 
all have aborted (note that due to different heuristic 
decisions of two participants" the semantics cannot 
be enforced). In the second scenario of the above 
example, the withdraw and DEPOSIT requests arc 
defined as an atomic sphere so that the wfms will 
ensure a consistent' end-of-transaction processing. 

Note the subtle but important difference to distrib- 
uted transactions: Rased on the syntactic specifica- 
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lion of an atomic sphere within a process model, it 
is the WFMS that establishes the transaction bound- 
aries dynamically (dependent on the execution context 
of the workflow). Thus, the activity implementation 
programmer is freed from this concern. In a raw dis- 
tributed transaction environment, programmers have 
to deal with it. 58 

At the operational level, each implementation of an 
activity within an atomic sphere is required to ex- 
ploit only resource managers in the sense of Ref- 
erence 38 and does not provide its own end -of- trans- 
action processing. 

Atomic spheres might become very helpful from a 
technical point of view. They permit, for example, 
the tying together of independent (and, in the above 
sense, well-behaving) transactions that are manip- 
ulating databases in such a way that if one transac- 
tion fails, the others are aborted, too. It significantly 
simplifies the task of managing the associated trans- 
actions. Nevertheless, atomic spheres should be ex- 
ploited very selectively because of their operational 
drawbacks. They use a two-phase commit protocol, 
which inherently strives toward holding locks until 
the end of the encompassing atomic sphere, thus re- 
ducing concurrency. In addition, many messages 
have to be sent so that there is a consensus to the 
outcome of all participating transactions. Both lock- 
ing and message traffic impact performance. There- 
fore, only a few short running transactional activ- 
ities should be bound into an atomic sphere. 

Mixing compensation spheres and atomic spheres. 
From a modeler's perspective, compensation spheres 
and atomic spheres arc overlaying the model of a 
business process. The result is that modelers will 
specify the processes of an enterprise and identify 
collections of activities that have to be explicitly un- 
done in case of an erroneous situation (in the sense 
of being repaired via a dedicated business process) 
and resumed afterwards. They will also specify col- 
lections of transactional activities that are undone 
(in the sense of simply restoring the manipulated re- 
sources to their original state) in case one of these 
transactions fails. The sphere definitions are stored 
in the wfms with the models of the business pro- 
cesses, resulting at run time in business transactions 
or extended transactions, respectively., managed by 
the wfms. 
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Summary 

We have shown that the basic routing features of a 
wfms allow the extraction of all flow information 
from an application similar to a DBMS that provides 
the means to extract all proper data management 
functions from an application. As a result, the ap- 
plication is both data-independent und flow-indepen- 
dent. Such a workflow-based application consists of 
a process model and a collection of activity imple- 
mentations. The activity implementations become 
a subject for reuse to be exploited in different pro- 
cess models. We have shown how potential trans- 
actional features of a wfms could further enhance 
the reusability of activity implementations. The task 
of writing activity implementations is reduced to re- 
alizing proper application logic or business functions. 
This task can be further eased dramatically by ex- 
ploiting visual builders, reusable parts, and business 
objects. 

Starting from an application developer's wish list, we 
have proposed an application development method 
and environment that facilitates the design, imple- 
mentation, and testing of workflow-based applica- 
tions. A three-phase approach, which includes an- 
imation, simulation, and monitoring, helps to verify 
the workflow-based application without an extensive 
setup of complex environments. A sample scenario 
showed partially how such an environment could be 
used by an application developer. 
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